Enumerating Windows Processes

In this article we will examine the following enumeration methods:

Some of methods covered in this article allows enumeration of processes on remote computers, therefore the enumeration function prototype has the pszMachineName parameter. The NULL value for this parameter means enumeration of processes on the local machine.

For process enumeration purposes, PSAPI provides the EnumProcesses function that returns an array of identifiers of currently running processes. Below is the source code of the EnumProcesses_PsApi function that implements process enumeration using PSAPI.

onclick="toggleCode('1')"> Listing 1. Enumerating processes with PSAPI

The EnumProcesses function does not provide a way to know how much space is needed to receive all the identifiers. To deal with this limitation, we call EnumProcesses in a loop, increasing the the buffer size until the returned array size becomes less than the buffer size we allocated. Since we want to obtain not only identifiers of processes but also their names, we have to do some additional work. For each process, we first get its handle with OpenProcess and then call EnumProcessModules, which returns a list of modules loaded into the process address space. The first module in the list is always the module representing the EXE-file used to create the process, so we get this handle and pass it to the GetModuleFileNameEx function (which is also a part of PSAPI) to obtain a path to the EXE-file. Finally, we strip path information from the file name and use this value as a process name. Note the special handling of two processes in the source code of EnumProcesses_PsApi. We need to handle the System Idle Process, which identifier is always zero, and the System Process, which identifier depends on the operating system version, separately, because OpenProcess does not allow to obtain a handle to these processes and fails with ERROR_ACCESS_DENIED error. If you run the demo application accompanying this article, you'll find that for at least one process the name is returned as "(name unavailable)". Using the Task Manager, it is easy to determine that this process is CSRSS.EXE. As it turns out, the system assigns such a security descriptor for this process, so it doesn't allow opening the process with access rights necessary to obtain its name. On one hand, we could use the same approach as with two system processes. However, there is no guarantee that the identifier of this process is always the same. On the other hand, this issue can be resolved by enabling the SE_DEBUG_NAME privilege. When this privilege is turned on, the calling thread can open process handles with any access rights regardless the security descriptor assigned to the process. Since this privilege opens great opportunities to peneterate system security, it is normally granted only to system administrators. Because of this, we decided to not include the code for enabling this privilege into the EnumProcesses_PsApi function. If necessary, you can enable this privilege before calling EnumProcesses_PsApi, and the function will be able to return a name for the CSRSS.EXE process as well.

The Windows NT operating system from very beginning provides an interface known as "performance data" to obtain similar information. This interface is very intricate and inconvenient (to be honest, beginning with Windows NT 4.0, Microsoft provides the Performance Data Helper library that greatly simplifies accessing performance data; we will use this library in one of our methods). Rumors are the Windows NT development team was refusing to include ToolHelp32 API into the system for long time, but anyway, starting with Windows 2000, you can see this API in the Windows NT family of operating systems. When using ToolHelp32 API, we first create a snapshot of the list of processes with the CreateToolhelp32Snapshot function and then walk through the list using Process32First and Process32Next functions. The PROCESSENTRY32 structure, which is filled by these functions, contains all the information we need. Below is the source code of the EnumProcesses_ToolHelp function that implements process enumeration using ToolHelp32 API.

onclick="toggleCode('2')"> Listing 2. Enumerating processes with ToolHelp32 API

The ZwQuerySystemInformation function has the following prototype [2]:

The format of processes and threads information buffer is described by the SYSTEM_PROCESS_INFORMATION structure, which contains almost all the information displayed by the Task Manager. Below you can find the source code for the EnumProcesses_NtApi function that implements process enumeration using ZwQuerySystemInformation.

onclick="toggleCode('3')"> Listing 3. Enumerating processes using ZwQuerySystemInformation

The SYSTEM_PROCESS_INFORMATION structure is a variable-size structure, the NextEntryDelta field specifies the offset to the next structure in the array. This field allows us to ignore the difference in size of the fixed part of the structure between Windows NT 4.0 and Windows 2000, where the IoCounters field was added to the structure.

Fortunately, the situation had changed with introducing the Performance Data Helper (PDH) library in Windows NT 4.0. This library provides more convenient interface to performance data. However, the library wasn't being shipped with Windows NT 4.0, it was available as a redistributable in the Microsoft Platform SDK. Beginning with Windows 2000, PDH became a part of the system. A detailed discussion of performance monitoring is beyond the scope of this article. Just let me note that the Windows NT performance monitoring architecture defines a concept of an object, for which performance counting is made. Examples of objects are processor and disk drive. Each object can have one or more instances along with a set of performance counters. Our ultimate goal is to enumerate all instances of the object named "Process", finding the value of the performance counter "ID Process" for each instance. Below is the code of the EnumProcesses_PerfData function, which uses PDH for process enumeration.

onclick="toggleCode('4')"> Listing 4. Enumerating processes using PDH

Object names and performance counter names are localizable. That means that, for example, on Russian version of Windows NT, process object and process identifier counter are no longer called "Process" and "ID Process", localized names are used instead. To get the localized names and format a full path to the performance counter we are interested in, we use a helper function named PerfFormatCounterPath. Its source code is provided below.

onclick="toggleCode('5')"> Listing 5. PerfFormatCounterPath source code

Note, among all process enumeration methods we discussed so far, this is the first method that allows to enumerate processes on another machine. All we have to do is to set the machine name in the szMachineName field of the PDH_COUNTER_PATH_ELEMENTS structure.

Any detailed discussion of WMI extends beyond the scope of this article. I'll just present the code that enumerates processes using WMI interfaces.

onclick="toggleCode('6')"> Listing 6. Enumerating processes using WMI interfaces

Furthermore, using WMI requires initialization of the COM security with a call to CoInitializeSecurity:

Important note: Remote process enumeration in the form as it presented in this article will work only if the current user of the local machine has administrative privileges on the remote machine. The samples provided above do not allow to change credentials with which a connection to the remote machine is made. To specify alternative credentials in PDH method, you should call NetUseAdd or WNetAddConnection2 to establish a connection with IPC$ resource on the remote machine prior to calling the enumeration function. In WMI method, you should use standard COM methods for supplying alternative credentials.